Implementering af Web Security Headers: JavaScript Content Security Policy (CSP)

I dagens digitale landskab er websikkerhed altafgørende. Cross-Site Scripting (XSS)-angreb udgør fortsat en betydelig trussel mod hjemmesider og deres brugere. Content Security Policy (CSP) er en kraftfuld web security header, der kan mindske XSS-risici ved at kontrollere de ressourcer, en browser har tilladelse til at indlæse for en given webside. Denne omfattende guide fokuserer på at implementere CSP ved hjælp af JavaScript for dynamisk kontrol og fleksibilitet.

Hvad er Content Security Policy (CSP)?

CSP er en HTTP response header, der fortæller browseren, hvilke kilder til indhold der er godkendt til indlæsning. Den fungerer som en hvidliste, der definerer de oprindelser, hvorfra ressourcer som scripts, stylesheets, billeder, skrifttyper og mere kan indlæses. Ved eksplicit at definere disse kilder kan CSP forhindre browseren i at indlæse uautoriseret eller ondsindet indhold, der er injiceret af angribere gennem XSS-sårbarheder.

Hvorfor er CSP vigtig?

• Mindsker XSS-angreb: CSP er primært designet til at forhindre XSS-angreb ved at begrænse de kilder, hvorfra browseren kan indlæse scripts.
• Reducerer angrebsfladen: Ved at kontrollere de ressourcer, der må indlæses, reducerer CSP den angrebsflade, der er tilgængelig for ondsindede aktører.
• Tilbyder et ekstra sikkerhedslag: CSP supplerer andre sikkerhedsforanstaltninger som inputvalidering og output-kodning, hvilket giver en dybdegående forsvarsstrategi.
• Forbedrer brugertilliden: Implementering af CSP viser en forpligtelse til sikkerhed, hvilket kan forbedre brugernes tillid og tiltro til din hjemmeside.
• Opfylder overensstemmelseskrav: Mange sikkerhedsstandarder og regulativer kræver eller anbefaler brugen af CSP for at beskytte webapplikationer.

CSP-direktiver: Kontrol af ressourceindlæsning

CSP-direktiver er de regler, der definerer de tilladte kilder for forskellige typer ressourcer. Hvert direktiv specificerer et sæt kilder eller nøgleord, som browseren kan bruge til at indlæse den tilsvarende ressource. Her er nogle af de mest almindeligt anvendte CSP-direktiver:

• `default-src`: Specificerer standardkilden for alle ressourcetyper, hvis et specifikt direktiv ikke er defineret.
• `script-src`: Specificerer de tilladte kilder for JavaScript-filer.
• `style-src`: Specificerer de tilladte kilder for CSS-stylesheets.
• `img-src`: Specificerer de tilladte kilder for billeder.
• `font-src`: Specificerer de tilladte kilder for skrifttyper.
• `connect-src`: Specificerer de tilladte kilder til at foretage netværksanmodninger (f.eks. AJAX, WebSockets).
• `media-src`: Specificerer de tilladte kilder for mediefiler (f.eks. lyd, video).
• `object-src`: Specificerer de tilladte kilder for plugins (f.eks. Flash). Det er generelt bedst at sætte denne til 'none', medmindre det er absolut nødvendigt.
• `frame-src`: Specificerer de tilladte kilder for frames og iframes.
• `base-uri`: Specificerer de tilladte base-URI'er for dokumentet.
• `form-action`: Specificerer de tilladte URL'er for formularindsendelser.
• `worker-src`: Specificerer de tilladte kilder for web workers og shared workers.
• `manifest-src`: Specificerer de tilladte kilder for applikationsmanifestfiler.
• `upgrade-insecure-requests`: Instruerer browseren til automatisk at opgradere usikre (HTTP) anmodninger til sikre (HTTPS) anmodninger.
• `block-all-mixed-content`: Forhindrer browseren i at indlæse ressourcer over HTTP, når siden indlæses over HTTPS.
• `report-uri`: Specificerer en URL, hvor browseren skal sende rapporter om CSP-overtrædelser. (Forældet, erstattet af `report-to`)
• `report-to`: Specificerer et gruppenavn defineret i `Report-To`-headeren, hvor rapporter om CSP-overtrædelser skal sendes. Dette er den foretrukne mekanisme til rapportering af CSP-overtrædelser.

Kildeudtryk

Inden for hvert direktiv kan du definere kildeudtryk for at specificere de tilladte oprindelser. Kildeudtryk kan omfatte:

• `*`: Tillader indhold fra enhver kilde (anbefales ikke til produktion).
• `'self'`: Tillader indhold fra samme oprindelse (skema, vært og port) som dokumentet.
• `'none'`: Tillader ikke indhold fra nogen kilde.
• `'unsafe-inline'`: Tillader inline JavaScript og CSS (frarådes kraftigt af sikkerhedsmæssige årsager).
• `'unsafe-eval'`: Tillader brugen af `eval()` og relaterede funktioner (frarådes kraftigt af sikkerhedsmæssige årsager).
• `'strict-dynamic'`: Tillader dynamisk oprettede scripts at blive indlæst, hvis de stammer fra en kilde, der allerede er betroet af politikken. Dette kræver en nonce eller en hash.
• `'unsafe-hashes'`: Tillader specifikke inline-hændelseshandlere med matchende hashes. Kræver, at den nøjagtige hash angives.
• `data:`: Tillader indlæsning af ressourcer fra data-URI'er (f.eks. indlejrede billeder). Brug med forsigtighed.
• `mediastream:`: Tillader `mediastream:`-URI'er at blive brugt som en mediekilde.
• URL'er: Specifikke URL'er (f.eks. `https://example.com`, `https://cdn.example.com/script.js`).

Implementering af CSP med JavaScript: En dynamisk tilgang

Mens CSP typisk implementeres ved at indstille `Content-Security-Policy` HTTP-headeren på serversiden, kan du også dynamisk administrere og konfigurere CSP ved hjælp af JavaScript. Denne tilgang giver større fleksibilitet og kontrol, især i komplekse webapplikationer, hvor kravene til ressourceindlæsning kan variere baseret på brugerroller, applikationstilstand eller andre dynamiske faktorer.

Indstilling af CSP-headeren via Meta Tag (Anbefales ikke til produktion)

For simple tilfælde eller testformål kan du indstille CSP ved hjælp af et ``-tag i HTML-dokumentet. Denne metode er dog generelt ikke anbefalet til produktionsmiljøer, fordi den er mindre sikker og mindre fleksibel end at indstille HTTP-headeren. Den understøtter også kun et begrænset undersæt af CSP-direktiver. Specifikt understøttes `report-uri`, `report-to`, `sandbox` ikke i meta-tags. Det er inkluderet her for fuldstændighedens skyld, men vær forsigtig!

            
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;">

            

              
                Copy
              
            
          

Generering af Nonces med JavaScript

En nonce (number used once) er en kryptografisk sikker tilfældig værdi, der kan bruges til at hvidliste specifikke inline-scripts eller styles. Browseren vil kun udføre scriptet eller anvende stilen, hvis den har det korrekte nonce-attribut, der matcher den nonce, der er specificeret i CSP-headeren. At generere nonces med JavaScript giver dig mulighed for dynamisk at oprette unikke nonces for hver anmodning, hvilket forbedrer sikkerheden.

            
function generateNonce() {
 const randomBytes = new Uint32Array(8);
 window.crypto.getRandomValues(randomBytes);
 let nonce = '';
 for (let i = 0; i < randomBytes.length; i++) {
 nonce += randomBytes[i].toString(16);
 }
 return nonce;
}

const nonceValue = generateNonce();

// Tilføj nonce til script-tagget
const script = document.createElement('script');
script.src = 'your-script.js';
script.setAttribute('nonce', nonceValue);
document.head.appendChild(script);

// Indstil CSP-headeren på serversiden (eksempel for Node.js med Express)
app.use((req, res, next) => {
 res.setHeader(
 'Content-Security-Policy',
 `default-src 'self'; script-src 'self' https://example.com 'nonce-${nonceValue}'; style-src 'self' https://example.com; img-src 'self' data:;`
 );
 next();
});

            

              
                Copy
              
            
          

Vigtigt: Nonce'en skal genereres på serversiden og sendes til klienten. JavaScript-koden vist ovenfor er kun til demonstrationsformål for at generere nonce'en på klienten. Det er afgørende at generere nonce'en på serversiden for at sikre dens integritet og forhindre manipulation af angribere. Eksemplet viser, hvordan man derefter bruger nonce-værdien i en Node.js/Express-applikation.

Generering af Hashes for Inline Scripts

En anden tilgang til hvidlistning af inline-scripts er at bruge hashes. En hash er et kryptografisk fingeraftryk af scriptets indhold. Browseren vil kun udføre scriptet, hvis dets hash matcher den hash, der er specificeret i CSP-headeren. Hashes er mindre fleksible end nonces, fordi de kræver, at man kender det nøjagtige indhold af scriptet på forhånd. Dog kan de være nyttige til at hvidliste statiske inline-scripts.

            
// Eksempel: Beregning af SHA256-hash af et inline-script
async function generateHash(scriptContent) {
 const encoder = new TextEncoder();
 const data = encoder.encode(scriptContent);
 const hashBuffer = await crypto.subtle.digest('SHA-256', data);
 const hashArray = Array.from(new Uint8Array(hashBuffer));
 const hashHex = hashArray
 .map((b) => b.toString(16).padStart(2, '0'))
 .join('');
 return `'sha256-${btoa(String.fromCharCode(...new Uint8Array(await crypto.subtle.digest('SHA-256', new TextEncoder().encode(scriptContent)))))}'`;
}

// Eksempel på brug:
const inlineScript = `console.log('Hello, CSP!');`;

generateHash(inlineScript).then(hash => {
 console.log('SHA256 Hash:', hash);
 // Indstil CSP-headeren på serversiden
 // Content-Security-Policy: default-src 'self'; script-src 'self' ${hash};
});

            

              
                Copy
              
            
          

Vigtigt: Sørg for, at hash-beregningen udføres korrekt, og at hashen i CSP-headeren nøjagtigt matcher hashen af inline-scriptet. Selv en enkelt tegns forskel vil få scriptet til at blive blokeret.

Dynamisk tilføjelse af scripts med CSP

Når du dynamisk tilføjer scripts til DOM'en ved hjælp af JavaScript, skal du sikre dig, at scriptsene indlæses på en måde, der er i overensstemmelse med CSP. Dette indebærer typisk brug af nonces eller hashes eller indlæsning af scripts fra betroede kilder.

            
// Eksempel: Dynamisk tilføjelse af et script med en nonce
function addScriptWithNonce(url, nonce) {
 const script = document.createElement('script');
 script.src = url;
 script.setAttribute('nonce', nonce);
 document.head.appendChild(script);
}

const nonceValue = generateNonce();

// Indstil CSP-headeren på serversiden
// Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com 'nonce-${nonceValue}';

addScriptWithNonce('https://example.com/dynamic-script.js', nonceValue);

            

              
                Copy
              
            
          

Rapportering af CSP-overtrædelser

Det er afgørende at overvåge CSP-overtrædelser for at identificere potentielle XSS-angreb eller fejlkonfigurationer i din CSP-politik. Du kan konfigurere CSP til at rapportere overtrædelser til en specificeret URL ved hjælp af `report-uri`- eller `report-to`-direktivet.

            
// Indstil CSP-headeren på serversiden
// Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;
// Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report"}]}

// Eksempel på Node.js-endpoint til at modtage CSP-rapporter
app.post('/csp-report', (req, res) => {
 console.log('CSP Violation Report:', req.body);
 res.sendStatus(204); // Svar med en 204 No Content-status
});

            

              
                Copy
              
            
          

Browseren sender en JSON-payload med detaljer om overtrædelsen, såsom den blokerede ressource, det overtrædende direktiv og dokumentets URI. Du kan derefter analysere disse rapporter for at identificere og løse sikkerhedsproblemer.

Bemærk, at `report-uri`-direktivet er forældet, og `report-to` er den moderne erstatning. Du skal konfigurere `Report-To`-headeren såvel som CSP-headeren. `Report-To`-headeren fortæller browseren, hvor rapporterne skal sendes hen.

CSP i Report-Only-tilstand

CSP kan implementeres i report-only-tilstand for at teste og finjustere din politik uden at blokere nogen ressourcer. I report-only-tilstand vil browseren rapportere overtrædelser til den specificerede URL, men vil ikke håndhæve politikken. Dette giver dig mulighed for at identificere potentielle problemer og justere din politik, før du håndhæver den i produktion.

            
// Indstil Content-Security-Policy-Report-Only-headeren på serversiden
// Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;
// Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report"}]}

// Eksempel på Node.js-endpoint til at modtage CSP-rapporter (samme som ovenfor)
app.post('/csp-report', (req, res) => {
 console.log('CSP Violation Report:', req.body);
 res.sendStatus(204); // Svar med en 204 No Content-status
});

            

              
                Copy
              
            
          

Bedste praksis for implementering af CSP

• Start med en streng politik: Begynd med en streng politik, der kun tillader de nødvendige ressourcer, og lemp den gradvist efter behov baseret på overtrædelsesrapporter.
• Brug Nonces eller Hashes til inline-scripts og -styles: Undgå at bruge `'unsafe-inline'` når det er muligt, og brug nonces eller hashes til at hvidliste specifikke inline-scripts og -styles.
• Undgå `'unsafe-eval'`: Deaktivering af `eval()` og relaterede funktioner kan markant reducere risikoen for XSS-angreb.
• Brug HTTPS: Servér altid din hjemmeside over HTTPS for at beskytte mod man-in-the-middle-angreb og sikre integriteten af dine ressourcer.
• Brug `upgrade-insecure-requests`: Dette direktiv instruerer browseren til automatisk at opgradere usikre (HTTP) anmodninger til sikre (HTTPS) anmodninger.
• Brug `block-all-mixed-content`: Dette direktiv forhindrer browseren i at indlæse ressourcer over HTTP, når siden indlæses over HTTPS.
• Overvåg CSP-overtrædelser: Overvåg regelmæssigt rapporter om CSP-overtrædelser for at identificere potentielle sikkerhedsproblemer og finjustere din politik.
• Test din politik: Test din CSP-politik grundigt i report-only-tilstand, før du håndhæver den i produktion.
• Hold din politik opdateret: Gennemgå og opdater din CSP-politik regelmæssigt for at afspejle ændringer i din applikation og sikkerhedslandskabet.
• Overvej at bruge et CSP-generatorværktøj: Flere onlineværktøjer kan hjælpe dig med at generere en CSP-politik baseret på dine specifikke krav.
• Dokumentér din politik: Dokumentér klart din CSP-politik og begrundelsen bag hvert direktiv.

Almindelige udfordringer og løsninger ved implementering af CSP

• Ældre kode: Integration af CSP i applikationer med ældre kode, der er afhængig af inline-scripts eller `eval()`, kan være udfordrende. Refaktorér gradvist koden for at fjerne disse afhængigheder eller brug nonces/hashes som en midlertidig løsning.
• Tredjepartsbiblioteker: Nogle tredjepartsbiblioteker kan kræve specifikke CSP-konfigurationer. Konsultér dokumentationen for disse biblioteker og juster din politik i overensstemmelse hermed. Overvej at bruge SRI (Subresource Integrity) til at verificere integriteten af tredjepartsressourcer.
• Content Delivery Networks (CDN'er): Når du bruger CDN'er, skal du sikre, at CDN-URL'erne er inkluderet i `script-src`, `style-src` og andre relevante direktiver.
• Dynamisk indhold: Dynamisk genereret indhold kan være vanskeligt at håndtere med CSP. Brug nonces eller hashes til at hvidliste dynamisk tilføjede scripts og styles.
• Browserkompatibilitet: CSP understøttes af de fleste moderne browsere, men nogle ældre browsere kan have begrænset understøttelse. Overvej at bruge en polyfill eller en server-side-løsning for at yde CSP-understøttelse til ældre browsere.
• Udviklingsworkflow: Integration af CSP i udviklingsworkflowet kan kræve ændringer i byggeprocesser og implementeringsprocedurer. Automatiser generering og implementering af CSP-headere for at sikre konsistens og reducere risikoen for fejl.

Globale perspektiver på CSP-implementering

Vigtigheden af websikkerhed er universelt anerkendt, og CSP er et værdifuldt værktøj til at mindske XSS-risici på tværs af forskellige regioner og kulturer. Dog kan de specifikke udfordringer og overvejelser ved implementering af CSP variere afhængigt af konteksten.

• Databeskyttelsesforordninger: I regioner med strenge databeskyttelsesforordninger som EU (GDPR) kan implementering af CSP hjælpe med at demonstrere en forpligtelse til at beskytte brugerdata og forhindre databrud.
• Mobile-First-udvikling: Med den stigende udbredelse af mobile enheder er det vigtigt at optimere CSP for mobil ydeevne. Minimer antallet af tilladte kilder og brug effektive caching-strategier for at reducere netværksforsinkelse.
• Lokalisering: Når du udvikler hjemmesider, der understøtter flere sprog, skal du sikre, at CSP-politikken er kompatibel med de forskellige tegnsæt og kodningsskemaer, der bruges i hvert sprog.
• Tilgængelighed: Sørg for, at din CSP-politik ikke utilsigtet blokerer ressourcer, der er afgørende for tilgængelighed, såsom skærmlæser-scripts eller stylesheets til hjælpeteknologi.
• Globale CDN'er: Når du bruger CDN'er til at levere indhold globalt, skal du vælge CDN'er, der har en stærk sikkerhedshistorik og tilbyder funktioner som HTTPS-understøttelse og DDoS-beskyttelse.

Konklusion

Content Security Policy (CSP) er en kraftfuld web security header, der markant kan reducere risikoen for XSS-angreb. Ved at implementere CSP ved hjælp af JavaScript kan du dynamisk administrere og konfigurere din sikkerhedspolitik for at imødekomme de specifikke krav i din webapplikation. Ved at følge de bedste praksisser, der er skitseret i denne guide, og løbende overvåge CSP-overtrædelser, kan du forbedre sikkerheden og tilliden til din hjemmeside og beskytte dine brugere mod ondsindede angreb. At omfavne en proaktiv sikkerhedsposition med CSP er afgørende i nutidens stadigt udviklende trusselslandskab.